What is SAML?

SAML (Security Assertion Markup Language) is an open source XML framework that enables the exchange of authentication and authorization information. The individual SAML components, which include a central user database and six different protocols, provide all relevant functions for describing and transferring security features - which is why SAML is considered an excellent complete solution for federated identity management (FIM).

Security assertion markup language, or SAML for short, is an open-source XML-based framework for exchanging authentication and authorization information. It was developed in 2001 by the security services technical committee of the OASIS consortium (organization for the advancement of structured information standards) and published in a first version (SAML v1.0) in November 2002. The project team has made various adaptations, which can be found in the revisions called SAML 2.0 and 2.1 (also 1.1). SAML contains several components that provide functions for describing and transmitting safety-related information. SAML is the optimal basis for federated identity management (FIM).

SAML can be used to make statements about the properties and authorizations of a user for other users or partner companies, but especially for applications (applications are also referred to as “service providers” in SAML). For this purpose, the so-called identity provider (central user database), which stores corresponding user information, uses assertions in an XML format. Other components of SAML-based verification are six different protocols, as well as bindings and profiles.

A SAML assertion can contain one or more statements about the characteristics (identity, attributes) of a user, as well as their authorizations. This assertion is created by the respective identity provider, i.e. the responsible user database, using XML as the markup language. Every assertion also receives a digital signature, which must be verified by the accessing a service provider. This guarantees the integrity and authenticity of the assertion, which is also called a SAML token in its signed form. After successful verification, the service provider analyzes the actual content, and then makes a decision on what kind of access is granted to the user.

The following three types of statements in SAML assertions are specified in SAML 2.0:

• Authentication statements: The identity provider informs the application that the user has been authenticated using authentication statements. This type of statement also provides information in an assertion about when the authentication took place and which method was used.
• Attribute statements: Attribute statements are attributes that are linked to the respective user, and can be communicated to the application using the corresponding SAML token.
• Authorization decision statements: When authorization decision statements are included in a SAML assertion, the user has either been granted access to specific resources or denied access to specific resources.

The SAML 2.0 specification defines a set of query/response protocols that allow the application to request or query an assertion, or request a user to authenticate. These are the following protocols:

• Authentication request protocol: The authentication request protocol defines messages of type <AuthnRequest> that are required to query assertions with authentication statements for a selected user. Based on this protocol, the information is transferred from the database to the service provider, usually using a “SAML 2.0 Web Browser SSO Profile” (more on this in the “profiles” section).
   
• Assertion query and request protocol: For queries that can be used to retrieve existing SAML assertions in general, the framework contains the assertion query and request protocol. The assertions can be queried on the basis of various parameters such as the statement types contained.
   
• Single logout protocol: The single logout protocol defines queries that initiate an almost simultaneous logout from all active sessions of a user. These kinds of messages can be sent by the user, identity provider, or service provider. The latter is particularly conceivable when a user session has expired.
   
• Artifact resolution protocol: If SAML messages are to be transported separately over a secure channel or in a resource-saving size, the artifact resolution protocol is used. It allows you to send references to assertions, also called artifacts, which are much smaller than the actual message. The log also allows you to resolve these references to receive the original message.
   
• Name identifier management protocol: This protocol provides means to change the name value or format of a user identity. The request can be written by either the service provider or the identity provider. You can also use the name identifier management protocol to remove links between service and identity providers that were created to authenticate the original user identity.
   
• Name identifier mapping protocol: The name identifier mapping protocol defines query and response messages for communication between two service providers. Based on this message type, an application can query an identity provider identifier for a user to access another application.

Mappings of SAML messages into standard messaging or communication protocols are called “SAML protocol bindings,” or simply “bindings.” For example, SOAP binding defines how SAML messages can be exchanged within SOAP environments, while HTTP redirect binding defines how SAML protocol messages can be transported using HTTP forwarding. Other bindings which are already predefined in SAML 2.0:

• Reverse SOAP binding
• HTTP POST binding
• HTTP artifact binding
• SAML URI binding

Generally speaking, SAML is characterized by its flexibility, which means that the framework can be used for many different purposes. However, for certain applications to support SAML, this flexibility must be partially restricted. For this to work, so-called profiles are used, which bundle selected SAML assertions, protocols, and bindings for specific applications. One of the most commonly used profiles is the “SAML 2.0 web browser” SSO profile, which specifies the framework for using SAML SSO authentication. It contains all the essential components for defining the communication of SAML authentication requirements between identity and service providers. The framework also provides the following additional profiles:

• Enhanced client and proxy (ECP) profiles
• Identity provider discovery profile
• Single logout profiles
• Name identifier management profile
• Artifact resolution profile
• Assertion query/request profile
• Name identifier mapping profile

More than 24 companies and organizations were involved in the development of SAML 2.0 before it was released in March 2005 as the official successor of SAML 1.0 and 1.1. In addition to numerous improvements of existing features, the framework also had completely new features, which are derived from the liberty alliance identity federation framework (ID-FF) 1.2 and from the shibboleth architecture.

Here’s a list of the most important changes made to the framework in the second major release:

• Removal of some obsolete elements such as <AuthorityBinding> or <RespondWith>
• Implementation of XML signature and XML encryption (according to W3C)
• Replacement of the AssertionID attribute with a general XML ID attribute
• Introduction of session management to support automatic log-offs from all applications (e.g. during long absences)
• Adaptation of the metadata to simplify the use of SAML (e.g. the identity provider and the service provider are now also marked in the metadata)
• The use of mechanisms that allow providers to communicate privacy policies and settings
• Improved support for mobile devices
• Implementation of the logs already listed (only the assertion query and request protocol existed in SAML 1.0 and 1.1)
• Profile optimization (e.g. merging the “browser/artifact” and “browser/post” profiles in the “SAML 2.0 web browser SSO profile”)

A detailed list of the differences between SAML 2.0 and SAML 1.1 can be found on the SAML community page saml.xml.org.

The field of application of the SAML framework is quickly defined: With the appropriate know-how, a central authentication instance can be implemented on the basis of the markup language, which is characterized by efficiency and a high security standard. In particular, the latter is due to the fact that the individual applications do not have to store or synchronize any user data, which significantly minimizes the number of possible security leaks. The main focus of the framework is to combine this high level of security with the best possible level of user-friendliness, which is why it also supports the single sign-on already mentioned several times thanks to appropriate protocols and message formats.

The SAML SSO procedure, which enables the use of different applications on the basis of a single log-on, is not only used for internal company application processes. It is also used for various web services – especially in online banking and mobile apps. As a customer, you’ll notice that you’re dealing with several different applications when using these kinds of services. For example, if you log on to your bank’s website once, you’ll most likely access more than one back end system. Thanks to SAML technology, however, it’ll seem as if you’re just on one program.